系列：那個 Agent 最後沒人用：30 個企業 AI 導入現場

這一篇要談的是：使用量不等於工作被完成。

季度檢討會進行到第十七分鐘，專案經理把最後一張圖表投到螢幕上。

藍色曲線從四月一路向上。

「上線三個月，使用次數增加 280%。三個部門都完成 Training，系統可用率維持在 99% 以上。」

主管點了點頭。這是整份簡報裡最好看的一頁。

這個 Agent 上線後沒有重大事故。權限檢查通過，知識庫固定同步，平均回應時間也在承諾範圍內。照專案計畫來看，該做的都做了。

坐在會議桌另一端的人問了一句：

「所以，它這三個月幫工程師完成了幾次 RCA？」

專案經理停了一下。

「你是指使用次數嗎？」

「不是。我是問，最後真的找到故障原因、讓工程師可以往下處理的，有幾次？」

負責數據的人打開後台。登入人數、對話數量、Token 用量、部門分布、每天的尖峰時段都有。

但沒有任何一個欄位能回答：這個 Agent 完成了幾次 Root Cause Analysis（RCA）。

於是他們隨機抽幾筆對話。

• 問端午節有沒有補假
• 請 Agent 把通知信改得客氣一點
• Training 當天留下的範例：「請根據以下 Log，分析可能的錯誤原因」
• 再往下二十多筆，幾乎都是開發團隊自己的測試帳號

主管看著那條曲線。

「所以大家確實有打開它，只是沒拿它做 RCA？」

這不是系統故障，也不是使用者不夠努力。

問題比較前面：專案一開始就沒有定義，什麼叫作「完成一次 RCA」。

「RCA Agent」其實不是工作定義

這個專案一開始就叫作「RCA Agent」。

名字看起來很具體：系統出問題後，它讀 Log、找文件、比對過去案例，再給可能原因。

取得資料
→ 分析異常
→ 推測原因
→ 產生建議

流程也沒有錯。

但立項時少了一段更基本的盤點：現在的 RCA 是誰做、怎麼做、卡在哪裡、最後要交出什麼。

例如：

• 哪一類問題最常進到 RCA？
• 第一輪判斷由誰做？
• 花時間的是找 Log、排除雜訊，還是理解系統之間的關係？
• 工程師缺的是資料、候選原因，還是可直接採取的下一步？
• 什麼輸出足以讓值班工程師停止搜尋、改去驗證某個假設？

這些問題沒有答案時，「RCA Agent」只是一個解法名稱。

團隊知道模型可以讀 Log，卻還不知道現場到底要它幫哪一段。

接下來很容易發生同一件事：輸出不符合期待，就被解釋成使用者還不習慣。於是再辦 Training、加範例、調整首頁、找部門 Champion。

這些做法會讓登入數提高，但它們處理的是推廣，不是工作本身。

Demo、上線、使用、完成工作，是四個不同層次

企業 AI 專案常把這四件事一起算進成功：

前三項都可能是真的。

但它們不會自動推到第四項。

登入一次，可能只是上課時跟著操作；對話量增加，可能是好奇、測試，或把它當一般聊天工具。即使有人用它改信件，也只能證明模型能回應，不能證明故障分析更快了。

如果立項時說要改善 RCA，Dashboard 至少要看得到這幾件事：

• 由 Agent 協助完成的 RCA 次數
• 從事件發生到提出可驗證假設的時間
• 使用者最後是否採用了 Agent 提出的方向
• 因為資料不足、錯誤或無法判定而轉人工的比例
• 對照原本流程，少掉了哪一個搜尋、整理或比對步驟

這些數字不需要一開始就全有。至少要先選一個，當成這個工具存在的理由。

先寫一頁 Problem Contract

這種問題不需要靠一份很長的需求文件處理。

先把下面幾項寫成一頁，通常就足以發現該不該做 Agent：

若這些欄位還填不出來，缺的通常不是 Prompt、模型或平台功能。

可能連 Agent 都不是答案。那個需求最後也可能只需要搜尋工具、Dashboard、固定流程，甚至一支 Script。

先把工作看清楚，再決定工具要停在哪裡，成本會低很多。

那條曲線後來還是上升了

後來團隊又辦了兩場 Training。

首頁多了範例問題，部門主管也提醒大家可以試用。使用數字確實再次增加。

只是下一次系統故障時，值班工程師還是打開原本的終端機、翻舊 Ticket，然後去問那位熟悉系統的人。

Agent 沒有壞。

它只是從一開始，就沒有被放進一份定義清楚的工作裡。

下一篇：Day 02｜會議室裡，沒有人知道第一個 Agent 要做什麼